-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CORE-538] Apply dYdX patches to Cosmos SDK 0.50.1 fork #30
Conversation
* Fix lint/gocritic error * Disable some workflow jobs
@lcwik your pull request is missing a changelog! |
5f8013b
to
21e77b6
Compare
This change pushes the mutex that was in the local client to the top level of the ABCI methods and uses the unsynchronized local client. A future change is intended to reduce the critical sections of the various ABCI methods. We also replace cometbft usage with dYdX fork.
@@ -184,6 +186,9 @@ type BaseApp struct { | |||
// including the goroutine handling.This is experimental and must be enabled | |||
// by developers. | |||
optimisticExec *oe.OptimisticExecution | |||
|
|||
// Used to synchronize the application when using an unsynchronized ABCI++ client. | |||
mtx sync.Mutex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question on DeliverTx
:
I see that on v0.47
fork we take the app.mtx
lock
Lines 418 to 429 in bdf96fd
func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) (res abci.ResponseDeliverTx) { | |
return app.DeliverTxShouldLock(req, true) | |
} | |
// DeliverTxShouldLock enables control of whether the lock should be acquired. The golang mutex | |
// is not reentrant so we enable conditional locking to prevent deadlock since cosmos-sdk/x/genutil.InitGenesis | |
// invokes DeliverTx from the ABCI++ InitGenesis method which already holds the lock. | |
func (app *BaseApp) DeliverTxShouldLock(req abci.RequestDeliverTx, needsLock bool) (res abci.ResponseDeliverTx) { | |
if needsLock { | |
app.mtx.Lock() | |
defer app.mtx.Unlock() | |
} |
DeliverTx
. How has this changed in v0.50
? This is the corresponding deliverTx
function - is it intended to not take the lock?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cosmos was re-entrant when delivering txs during block commit which is why we needed the ability to selectively take the lock. CometBFT pushed down block commit logic of individually calling DeliverTx
into FinalizeBlock
which means that we could elevate the need for acquiring the lock to FinalizeBlock
removing it from deliverTx
which also meant that we didn't care any more that Cosmos was re-entrant for this method or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation. I see from here tha BeginBlock
, DeliverTx
, and EndBlock
are coalesced into FinalizeBlock
@@ -901,6 +937,9 @@ func (app *BaseApp) checkHalt(height int64, time time.Time) error { | |||
// against that height and gracefully halt if it matches the latest committed | |||
// height. | |||
func (app *BaseApp) Commit() (*abci.ResponseCommit, error) { | |||
app.mtx.Lock() | |||
defer app.mtx.Unlock() | |||
|
|||
header := app.finalizeBlockState.ctx.BlockHeader() | |||
retainHeight := app.GetBlockRetentionHeight(header.Height) | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: do we still need the commiter
logic from here? Or is that replaced by the prepareCheckStater
below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is replaced by prepareCheckStater
which @prettymuchbryce pushed upstream as the replacement for the committer
logic.
|
||
return gInfo, result, anteEvents, err | ||
} | ||
|
||
// runTx processes a transaction within a given execution mode, encoded transaction | ||
// bytes, and the decoded transaction itself. All state transitions occur through | ||
// a cached Context depending on the mode provided. State only gets persisted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question for runTx()
below: do we still need these checks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, added it back and updated the [STAB-19] Reduce the size of the critical section
commit to contain it to keep the history clean.
To confirm, do we still need to port over these changes from the |
For my understanding, how do we plan to test the upgrade from |
Just added these now to this PR. |
This is TBD, my thoughts around this are:
|
This change makes a copy of `runTx` and does the following: * moves transaction descoding and tx validation before lock acquisition * moves creation of the response after releasing the lock * removes support for the post handler (unused by dYdX) and extracts out the only code that is executed in `runMsgs` allowing us to avoid the creation of the `runMsgCtx` and its associated `MultiStore` * removes `consumeBlockGas` since it is only executed during `deliverTx`
ctx.Done() support was added in 0.50 with cosmos#15041 server start up time was removed in 0.50 with cosmos#15041
I was able to add the last of the remaining commits. I flattened these two commits together (5402055, b95c66d). And the CLOB-930 commit was able to be simplified a bunch because of changes that were released in 0.50 (cosmos#15041). |
Description
Apply dYdX patches to Cosmos SDK 0.50.1 fork
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change